Вчера мы писали о том, как правильно обслуживать ISL-соединение растянутого кластера VMware vSAN. В этой статье был упомянут механизм vSAN Adaptive Quorum Control, который позволяет сохранять работоспособность растянутого кластера vSAN даже при последовательных отказах (например, сначала отказывает основная площадка, а затем и компонент Witness).

Видео ниже объясняет механику голосования, используемую vSAN в случае отказа одного из сайтов и последующего отказа Witness. Адаптивное управление кворумом присваивает больше голосов выжившему сайту, чтобы обеспечить обработку последующего отказа сайта свидетеля. Путем присвоения 3 голосов компонентам на выжившем сайте по-прежнему соблюдается большинство голосов. Даже если дополнительный хост ESXi на предпочтительном сайте потерян, всё равно есть достаточно голосов для достижения большинства, поэтому виртуальные машины продолжат функционировать.

Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (ISL) растянутого кластера VMware vSAN. Обычно, если условия позволяют, можно потушить все рабочие нагрузки (ВМ) на обеих площадках, после чего можно выключить кластеры и проводить обслуживание сетевого линка между площадками. Эта процедура описана в KB 2142676.

Но что делать в случае, когда вам нужно, чтобы рабочие нагрузки на одной из площадок продолжили выполняться во время обслуживания ISL?

В VMware vSAN 7 Update 3 появился механизм vSAN Witness Resiliency, который мы подробно описывали в статье "Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах". Он позволяет сохранять кворум в кластере и его функционирование при последовательных отказах - сначала одного из датацентров, а потом и компонента Witness.

Этот механизм и можно использовать для обслуживания ISL-соединения. Итак, переводим все хосты кластера на сайте 1 в режим обслуживания (Maintenance Mode) или выключаем их. В этом случае в растянутом кластере голоса для компонента Witness будут пересчитаны в течение 3 минут. После этого можно выключить и сам Witness - и это не приведет к падению виртуальных машин на сайте 2.

Итак, как он это проверял. Сначала перевел все хосты сайта 1 в режим обслуживания - и все его виртуальные машины начали переезд на второй сайт.

Затем он проверил RVC-консоль (как мы писали выше) и дождался, пока за пару минут будут пересчитаны голоса. Далее он просто выключил компонент Witness, после чего он убедился, что все ВМ продолжили нормально работать на второй площадке:

После этого можно начинать обслуживание ISL-соединения и работы по улучшению межкластерного соединения.

Для верности можно выполнить команду vsan.vm_object_info в консоли RVC и проверить объекты/экземпляры виртуальных машин на предмет того, что они находятся в статусе "ACTIVE" вместо "ABSENT":

После завершения обслуживания ISL-линка, вы можете включить компонент Witness, после чего включаете обратно хосты сайта 1 и обязательно выполняете ресинхронизацию (resync). После этого механизм VMware DRS в автоматическом режиме сам сбалансирует нагрузки по площадкам, распределив их по ним с помощью vMotion.

Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Ранее мы рассказывали об объектах Storage Pools в vSAN ESA, а также о реализации механизмов повышенной производительности в VMware vSAN 8 Update 1. Ну а недавно компания VMware опубликовала интересное видео, в котором рассказывается о производительности vSAN ESA в сравнении с OSA:

Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):

Результаты теста SPEC - время отклика при увеличении числа операций в секунду:

Зависимость задержек (latency) от числа снапшотов на хранилище:

Также почитайте, как именно улучшения производительности VMware vSAN 8 Update 1 влияют на разные типы приложений.

Распределенная архитектура vSAN всегда была естественным решением для множества топологий, таких как растянутые кластеры, 2-узловые кластеры и кластеры, использующие домены отказа (fault domains). Но что насчет vSAN Max? Давайте рассмотрим, как vSAN Max может помочь обеспечить централизованное общее хранилище для ваших кластеров vSphere, используя эти альтернативные топологии.

Гибкость распределенного объектного хранилища

Кластер vSAN HCI объединяет вычислительные ресурсы и хранилища на одних и тех же хостах, которые составляют кластер, что обеспечивает простой и мощный способ создания растянутого кластера. Просто разместите хосты vSAN в кластере на двух географических площадках вместе с виртуальным хостом Witness на третьем сайте и настройте кластер как растянутый (stretched). И вычислительные ресурсы, и хранилища распределены по площадкам в единой, согласованной манере, что обеспечивает доступность экземпляров виртуальных машин и их данных в случае частичного или полного сбоя сайта.

Хост Witness не показан ниже для ясности на всех иллюстрациях растянутых кластеров в этом посте.

Рисунок 1. Отказоустойчивость на уровне сайта для виртуальных машин в растянутом кластере vSAN HCI, охватывающем два центра обработки данных.

Данные хранятся отказоустойчиво на разных площадках, что означает наличие двух путей от вычислительных ресурсов к данным. Поскольку вычислительные ресурсы и хранилища объединяются на одних и тех же хостах, которые составляют кластер vSAN, изначально существует архитектура высокой доступности для обоих типов ресурсов и предпочтительного пути данных, что является одной из причин, по которой растянутый кластер vSAN HCI может автоматически учитывать сценарии сбоев и другие стрессовые условия.

Растянутые топологии, использующие разделенные хранилища и вычислительные ресурсы

Концептуально растянутая топология подразумевает, что данные избыточно хранятся в двух определенных доменах отказоустойчивости – обычно (но не всегда) на двух географически разнесенных площадках. Это предположение должно учитываться в такого рода среде при рассмотрении топологий.

Когда вычислительные ресурсы и хранилища отделены друг от друга, они должны понимать характеристики двух сетевых путей от вычислительных ресурсов к избыточным данным. В большинстве случаев один из сетевых путей (межсайтовая связь или ISL) будет медленнее другого. Это называется асимметричной сетевой топологией, как показано на Рисунке 2. Хотя это наиболее распространенная конфигурация для растянутого кластера, она представляет интересную задачу, потому что система должна правильно выбрать оптимальный сетевой путь вместо менее быстрого для лучшей производительности.

Рисунок 2. Асимметричные сетевые топологии для растянутых сред.

Гораздо менее распространенная симметричная сетевая топология показана на рисунке 3. Это представляет собой топологию, где пропускная способность и задержка остаются одинаковыми независимо от выбранного пути данных для выполнения запроса. Такую ситуацию можно увидеть, когда два домена отказа или "сайта", как их определяют, представляют собой просто стойки серверов, расположенные рядом друг с другом и использующие одно и то же сетевое оборудование, что обеспечивает задержку менее 1 мс между клиентским кластером и серверным кластером внутри одного домена отказа или между доменами.

Рисунок 3. Симметричные сетевые топологии для растянутых сред.

Чтобы помочь vSAN Max понять правильный сетевой путь в топологии растянутого кластера, мастер настройки vSAN Max позволит вам выбрать сетевую топологию, соответствующую вашей среде.

vSAN Max, растянутый между географическими сайтами

Кластер vSAN Max может быть настроен как кластер одного сайта или в растянутой конфигурации. vSAN Max может обеспечивать устойчивость данных на уровне сайта, зеркалируя данные между сайтами, и вторичные уровни отказоустойчивости с помощью эффективного для экономии места схемы хранения RAID-6 erasure coding в пределах каждого сайта. Это обеспечивает высокий уровень отказоустойчивости эффективным способом и гарантирует, что восстановление данных будет выполнено локально в случае отдельного сбоя хоста в пределах сайта.

Рисунок 4 иллюстрирует растянутый кластер vSAN HCI, который подключает хранилище кластера vSAN Max, также растянутого. В этом типе асимметричной конфигурации кластер vSAN HCI и кластер vSAN Max будут поддерживать наибольшую близость сайтов обработки ввода-вывода и данных между клиентским и серверным кластерами.

Рисунок 4. Растянутый кластер vSAN Max обеспечивает устойчивое хранение данных на двух сайтах обработки данных для кластера vSAN HCI, который также является растянутым.

Рекомендация: используйте профили ReadyNode, сертифицированные для vSAN Max, для всех развертываний vSAN Max.

Поддерживаемые клиентские кластеры при использовании vSAN Max в растянутой топологии

Следующая таблица резюмирует типы клиентских кластеров, поддерживаемых при использовании кластера vSAN Max в конфигурации растянутого кластера. Предполагается, что требование к задержке в 1 мс или меньше между клиентским кластером и кластером vSAN Max выполнено, и предполагается, что все клиентские кластеры используют vSphere 8.

Как отмечено выше, когда кластер vSAN Max настроен как растянутый с использованием асимметричной сетевой топологии, кластер vSphere, подключающий хранилище данных vSAN Max и растянутый на тех же двух сайтах - в настоящее время не поддерживается. Если требуется отказоустойчивость данных и экземпляров виртуальных машин на уровне сайта, кластер vSAN HCI в качестве клиентского кластера в растянутой конфигурации может быть лучшим вариантом на данный момент. Это обеспечит высокую доступность экземпляров виртуальных машин и обслуживаемых ими данных.

При использовании в конфигурации растянутого кластера кластеры vSAN Max будут иметь те же требования к пропускной способности и задержке сети между сайтами, что и традиционные кластеры vSAN HCI того же размера. Смотрите руководство по размерам пропускной способности растянутых кластеров vSAN для получения дополнительной информации.

Рекомендация. Размер вашей межсайтовой связи (ISL) должен быть основан на требованиях вашей рабочей нагрузки. Учитывая, что кластер vSAN Max может предложить высокопроизводительное хранилище, убедитесь, что ISL может обеспечить необходимую пропускную способность и задержку для ваших рабочих нагрузок. Это означает, что ваша среда может потребовать более 10 Гбит/с пропускной способности, указанной как минимально необходимая для этого типа топологии.

vSAN Max с использованием функции доменов отказа vSAN

vSAN Max также может быть настроен с использованием функции Fault Domains, которая чаще всего используется для обеспечения отказоустойчивости на уровне стоек для больших кластеров. Функция доменов отказа стала гораздо более эффективной с ESA, и поскольку vSAN Max построен на этой архитектуре, он обеспечивает все улучшенные уровни производительности, эффективности и доступности данных, связанные с ESA.

Рисунок 5. vSAN Max обеспечивает устойчивость на уровне стоек с использованием функции доменов отказа.

Будучи настроенной правильно, функция доменов отказа обычно ограничивается большими кластерами. Это связано с тем, что, как показано на рисунке 5 выше, RAID-6 распределяет данные и четность по минимум шести доменам отказоустойчивости, и VMware рекомендует использовать по крайней мере 3 хоста на каждый домен отказа. Для достижения такой же устойчивости на уровне стоек с использованием относительно меньшего кластера можно просто разместить один (и не более одного) хоста в кластере vSAN Max на стойку, не включая функцию доменов отказа, как показано на рисунке 6. В этой конфигурации он обеспечит устойчивость на уровне стоек таким же образом.

Рисунок 6. vSAN Max обеспечивает устойчивость на уровне стоек без использования функции доменов отказа.

Такой тип стратегии изменит способ прохождения трафика vSAN через сетевое оборудование и должен быть частью вашего планирования при проектировании кластера vSAN Max.

Хотя типичная рекомендация VMware - включать опцию "Host Rebuild Reserve" для кластеров vSAN Max, обратите внимание, что эти переключатели не могут быть включены при настройке vSAN Max в растянутой топологии или при использовании функции доменов отказа vSAN.

В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

В конце октября вышел очередной апдейт этого сверхполезного документа на 100 страницах - "Performance Best Practices for VMware vSphere 8.0 Update 2".

В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere (страница 11)
• ESXi and Virtual Machines (страница 25)
• Guest Operating Systems (страница 55)
• Virtual Infrastructure Management (страница 67)

Предполагается, что читатель уже в достаточной степени осведомлен о методах управления виртуальной инфраструктурой и ее основных компонентах.

Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.

Недавно мы писали о сайзинге пропускной способности канала для растянутых кластеров VMware vSAN Stretched Clusters, а сегодня поговорим о том, какие технологии и архитектуры поддерживаются для функций Datastore Sharing в данном типе кластеров. Давайте посмотрим на поддержку Datastore Sharing в рамках разных сценариев, для которых работают архитектуры HCI Mesh и vSAN Max.

О поддержке данных возможностей для растянутых кластеров рассказал Дункан Эппинг. В своей заметке он ссылается на раздел vSAN Max and Disaggregated storage страницы часто задаваемых вопросов по vSAN.

Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:

• Датастор vSAN Stretched Cluster, расшаренный с vSAN Stretched Cluster –> Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с vSAN Cluster (не stretched) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (не stretched) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, symmetric) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, asymmetric) –> Не поддерживается

В чем разница между симметричным и асимметричным растянутым кластером? На следующем изображении, взятом из конфигурации vSAN Stretched Cluster, это лучше всего объяснено:

Если вы используете растянутый кластер vSAN и растянутый Compute Only, то обычно используется Asymmetric-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.

Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.

В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).

Минимально поддерживаемая пропускная способность и latency между сайтами

Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.

Также вы можете использовать vSAN Sizer в сочетании с руководством по проектированию vSAN, чтобы создать оптимальную конфигурацию для вашего растянутого кластера.

Требования к пропускной способности между сайтами

Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.

Понимание активности I/O, соотношения чтения и записи и размеров I/O

Рабочие нагрузки состоят из нескольких характеристик. Не только количество активности I/O значительно различается от нагрузки к нагрузке, но чтения и записи часто происходят с разными скоростями и разными размерами I/O. С целью предоставления простой формулы для расчета мы будем использовать следующие переменные для расчета оценочной пропускной способности связи между сайтами для растянутого кластера (ISL):

• Скорость I/O всех команд чтения и записи, измеряемая в IOPS
• Соотношение чтения/записи (например, 70/30)
• Средний размер I/O, измеряемый в KB

Пропускная способность - это измерение на основе скорости, что означает, как много данных передается за определенный период времени. В отличие от измерения неактивных данных, где оно принимает форму байтов, килобайтов и т. д., измерение данных в процессе передачи по сети выражается в битах (b), килобитах (Kb), мегабитах (Mb) или гигабитах (Gb), и период времени - "в секунду" (ps). Обсуждая скорости, мы должны помнить о конвертации байтов в биты.

Давайте используем простой пример, где общий профиль I/O требует 100 000 I/O в секунду (IOPS), в среднем 8 KB каждый, где 70% IOPS - это чтение, и 30% - запись, в растянутой конфигурации. В этом сценарии запись I/O (30 000 IOPS в среднем 8 KB каждый) будет равна 240 000 Kbps или 240 Mbps. Это будет оценкой пропускной способности ISL, необходимой для этого профиля.

Простейший, но потенциально менее точный способ оценки требований к пропускной способности - это просто использовать входные данные, представляющие общие потребности кластера. Если кто-то использует формулу для расчета отдельных рабочих нагрузок в кластере, сумма этих расчетов предоставит результирующие требования к пропускной способности. Возможно, вы захотите выделить гораздо больше минимального рассчитанного количества, так как рабочие нагрузки со временем неизбежно становятся более ресурсоемкими.

Формулы для расчета оценок пропускной способности указаны ниже, они привязаны к используемой архитектуре: vSAN OSA или vSAN ESA. С введением архитектуры vSAN Express Storage (ESA) появляются все новые возможности по обеспечению производительности хранилища на совершенно новом уровне. Поэтому при использовании ESA рекомендуется тщательно отслеживать использование ISL, чтобы убедиться, что есть достаточная пропускная способность, необходимая для того, чтобы рабочие нагрузки не были ограничены со стороны ISL. Для дополнительной информации см. статью: "Использование vSAN ESA в топологии растянутого кластера".

Формулы расчета пропускной способности для vSAN ESA

Трафик репликации от I/O гостевой ВМ - это доминирующий тип трафика, который мы должны учесть при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). У растянутых кластеров vSAN ESA трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ. Требуемая пропускная способность между двумя сайтами данных (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr) * коэффициент сжатия (CR).

Расчет пропускной способности для ISL, обслуживающего растянутый кластер vSAN с использованием ESA, отличается от формулы, используемой для OSA. vSAN ESA сжимает данные до их репликации между сайтами. В результате ESA уменьшает использование пропускной способности ISL, эффективно увеличивая его возможности для передачи большего количества данных.

Чтобы учесть это в расчете в топологии, использующей ESA, формула учитывает оценочное соотношение сжатия сохраненных данных. Давайте рассмотрим следующий пример, где мы оцениваем экономию в 2 раза благодаря использованию сжатия в vSAN ESA. Мы используем простое значение "2x" (также называемое 2:1 или 50%) для простоты. Фактические коэффициенты сжатия будут зависеть от данных, хранящихся в вашей среде. Пример 2:1 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.

1. Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
2. Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".50".
   В результате формула будет выглядеть так:

B = Wb * md * CR * mr * CR

Как отмечалось выше, коэффициенты сжатия часто могут быть представлены разными способами, чтобы выразить экономию места.

Например:

• Сжатие, выраженное в соотношении. [начальный размер]:[конечный размер]. Соотношение сжатия 2:1 указывает на то, что данные будут сжаты до половины своего исходного размера.
• Сжатие, выраженное в виде множителя экономии. Соотношение сжатия 2x указывает на то, что данные будут сжаты до половины своего исходного размера. Это то, что отображается в представлении ёмкости кластера vSAN.
• Сжатие, выраженное в процентах от исходного размера. Значение сжатия 50% (или, .50) указывает на то, что данные будут сжаты до половины своего исходного размера.

Примеры между сайтами (для vSAN ESA)

• Рабочая нагрузка 1

С примером рабочей нагрузки в 10 000 записей в секунду на рабочую нагрузку vSAN со средним размером записи 8 KB потребуется 80 МБ/с или 640 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.

B = 640 Мбит/с * 1.4 * 1.25 * .50 = 560 Мбит/с.

Учитывая требования к сети vSAN, требуемая пропускная способность составляет 560 Мбит/с.

• Рабочая нагрузка 2

В другом примере, 30 000 записей в секунду, 8KB записи, потребуется 240 MB/s или 1 920 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.

B = 1,920 Мбит/с * 1.4 * 1.25 * .50 = 1,680 Мбит/с или примерно 1,7 Гбит/с.

Требуемая пропускная способность составляет примерно 1,7 Гбит/с.

Рабочие нагрузки редко состоят только из чтений или записей, и обычно включают общее соотношение чтения к записи для каждого варианта использования. Используя общую ситуацию, когда общий профиль I/O требует 100 000 IOPS, из которых 70% являются записью, а 30% чтением, в растянутой конфигурации, IO записи - это то, на что рассчитана пропускная способность межсайтовой связи. С растянутыми кластерами vSAN, трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ.

Формулы расчета пропускной способности для vSAN OSA

Как и в растянутых кластерах с использованием ESA, трафик репликации от I/O гостевой ВМ в растянутом кластере с использованием OSA является доминирующим типом трафика, который мы должны учитывать при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). В растянутых кластерах vSAN OSA трафик чтения по умолчанию обслуживается сайтом, на котором размещена ВМ. Требуемая пропускная способность между двумя данными сайтами (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr), или:

B = Wb * md * mr

Множитель данных состоит из накладных расходов на трафик метаданных vSAN и различных связанных операций. VMware рекомендует использовать множитель данных 1.4. Множитель ресинхронизации включен для учета событий ресинхронизации. Рекомендуется выделять пропускную способность по верхней границе требуемой пропускной способности для событий ресинхронизации. Для учета трафика ресинхронизации рекомендуются дополнительные 25%.

Планируйте использование vSAN ESA для всех новых кластеров vSAN. Эта архитектура быстрее и эффективнее, чем vSAN OSA, и, зачастую, уменьшает количество хостов, необходимых для того же объема рабочих нагрузок. Формула для vSAN OSA остается актуальной для тех, у кого уже есть установки vSAN OSA.

Требования к пропускной способности между Witness и сайтом данных

В топологии растянутого кластера хост-машина Witness просто хранит компоненты, состоящие из небольшого объема метаданных, которые помогают определить доступность объектов, хранящихся на сайтах с данными. В результате сетевой трафик, отправляемый на сайт для этой машины, довольно мал по сравнению с трафиком между двумя сайтами с данными через ISL.

Одной из наиболее важных переменных является объем данных, хранящихся на каждом сайте. vSAN хранит данные в виде объектов и компонентов. Она определяет, сколько компонентов нужно для данного объекта, и где они должны быть размещены по всему кластеру, чтобы поддерживать устойчивость данных в соответствии с назначенной политикой хранения.

Архитектура vSAN ESA обычно использует больше компонентов, чем OSA. Это следует учитывать при расчете потенциально необходимой пропускной способности для машины Witness.

Обязательно выберите правильный размер хоста vSAN Witness. При развертывании предлагается четыре размера машины (Tiny, Medium, Large и Extra Large), каждый из которых предназначен для размещения разных размеров сред. Посмотрите статью "Deploying a vSAN Witness Appliance" для получения дополнительной информации.

Формулы расчета пропускной способности Witness для vSAN ESA и OSA

Сетевое взаимодействие сайтов с Witnessn состоит исключительно из метаданных, что делает запросы к сетевым ресурсам Witness гораздо более легковесными, что отражается в поддерживаемых минимальных требованиях к пропускной способности и задержке.

Поскольку формула для оценки необходимой пропускной способности Witness основана на количестве компонентов, ее можно использовать для расчета растянутых кластеров, использующих OSA или ESA. Поскольку ESA обычно использует больше компонентов на объект (возможно, в 2-3 раза больше) по сравнению с OSA, следует учитывать большее количество компонентов на ВМ при использовании архитектуры на базе ESA.

Базовая формула

Требуемая пропускная способность между Witness и каждым сайтом равна ~1138 Б x Количество компонентов / 5с

1138 Б x Кол-во компонентов / 5 секунд

Значение 1138 Б происходит от операций, которые выполняются, когда предпочтительный сайт выходит из строя, и второстепенный сайт берет на себя владение всеми компонентами. Когда основной сайт выходит из строя, второстепенный сайт становится лидером. Witness отправляет обновления новому лидеру, после чего новый лидер отвечает Witness, по мере обновления владения. Требование в 1138 Б для каждого компонента происходит из сочетания полезной нагрузки от Witness к резервному агенту, за которым следуют метаданные, указывающие, что предпочтительный сайт не работает. В случае отказа предпочтительного сайта, связь должна быть достаточно хорошей, чтобы позволить изменение владения кластером, а также владение всеми компонентами в течение 5 секунд.

Примеры пропускной способности Witness к сайту (OSA)

• Нагрузка 1

Если ВМ состоит из:

• 3 объектов
• Параметр допустимого числа отказов (FTT=1)

Приблизительно 166 ВМ с этой конфигурацией потребовало бы, чтобы Witness содержал 996 компонентов (166 ВМ * 3 компонента/ВМ * 2 (FTT+1) * 1 (Ширина полосы)). Чтобы успешно удовлетворить требования пропускной способности Witness для общего числа 1 000 компонентов на vSAN, можно использовать следующий расчет:

Преобразование байтов (Б) в биты (б), умножьте на 8:

В = 1138 Б * 8 * 1 000 / 5с = 1 820 800 бит в секунду = 1.82 Мбит/с

VMware рекомендует добавить безопасный запас в 10% и округлить вверх.

B + 10% = 1.82 Мбит/с + 182 Кбит/с = 2.00 Мбит/с

Таким образом, с учетом безопасного запаса в 10%, можно утверждать, что для каждых 1 000 компонентов подходит канал 2 Мбит/с.

• Нагрузка 2

Если ВМ состоит из:

• 3 объектов
• FTT=1
• Stripe с параметром 2

Приблизительно 1 500 ВМ с этой конфигурацией потребовало бы хранения 18 000 компонентов на Witness. Чтобы успешно удовлетворить требования пропускной способности Witness для 18 000 компонентов на vSAN расчет будет таким:

B = 1138 Б * 8 * 18 000 / 5с = 32 774 400 бит в секунду = 32.78 Мбит/с
B + 10% = 32.78 Мбит/с + 3.28 Мбит/с = 36.05 Мбит/с

Используя общее уравнение 2 Мбит/с на каждые 1 000 компонентов, (NumComp/1000) X 2 Мбит/с, можно увидеть, что 18 000 компонентов действительно требует 36 Мбит/с.

Пропускная способность Witness для конфигураций с 2 узлами (OSA)

• Пример удаленного сайта 1

Рассмотрим пример 25 ВМ в конфигурации с 2 узлами, каждая с виртуальным диском 1 ТБ, защищенные при FTT=1 и Stripe Width=1. Каждый vmdk будет состоять из 8 компонентов (vmdk и реплика) и 2 компонентов для пространства имен ВМ и swap-файла. Общее количество компонентов составляет 300 (12/ВМx25ВМ). С 300 компонентами, используя правило (300/1000 x 2 Мбит/с), требуется пропускная способность 600 кбит/с.

• Пример удаленного сайта 2

Рассмотрим другой пример 100 ВМ на каждом хосте, с таким же ВМ выше, с виртуальным диском 1 ТБ, FTT=1 и SW=1. Общее количество компонентов составляет 2 400. Используя правило (2 400/1000 x 2 Мбит/с), требуется пропускная способность 4.8 Мбит/с.

Вот так и рассчитывается пропускная способность для разных рабочих нагрузок и конфигураций в среде vSAN. Понимание этих метрик и формул поможет в проектировании и развертывании решений vSAN, которые обеспечивают оптимальную производительность и надежность.

Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.

Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.

Референсная архитектура Microsoft SQL Server на платформе VMware vSAN ESA посвящена запуску Microsoft SQL Server на VMware vSAN ESA с Lenovo ThinkAgile VX Series.

В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.

Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.

В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.

Дункан Эппинг поднял вопрос о том, необходимо ли указывать 2 параметра Isolation Address в растянутом кластере VMware vSAN (stretched cluster), которые используются механизмом VMware HA.

Вопрос всплыл в связи с документацией по vSAN, где говорится о том, что вам нужно иметь 2 адреса на случай изоляции кластера в целях разумной избыточности:

Некоторые пользователи спрашивали, могут ли они использовать один Gateway Address от Cisco ACI, который будет доступен в обоих местах, даже если произойдет разделение, например, из-за сбоя ISL. Если это действительно так, и IP-адрес действительно доступен в обоих местах во время таких сбоев, то достаточно использовать один IP-адрес в качестве адреса изоляции.

Тем не менее, вам нужно удостовериться, что IP-адрес пингуется через сеть vSAN при использовании vSAN в качестве платформы для расширенного хранения данных. Ведь когда vSAN активирован, vSphere HA использует именно сеть vSAN для управляющих сигналов. Если адрес пингуется, вы можете просто задать адрес изоляции, установив расширенную настройку "das.isolationaddress0". Также рекомендуется отключить использование стандартного шлюза управляющей сети, установив "das.usedefaultisolationaddress" в значение false для сред, использующих vSAN в качестве платформы.

С появлением архитектуры vSAN Express Storage Architecture (ESA) в vSAN 8, которая была представлена в августе 2022 года, VMware хотела предоставить простой способ для клиентов развертывать кластеры с соответствующими характеристиками оборудования и сети. Программа vSAN ReadyNode для ESA гарантировала, что клиенты могут приобретать серверы, предварительно настроенные для выполнения конкретных минимальных требований к оборудованию для ESA, предоставляя при этом достаточную гибкость для удовлетворения требований к емкости и производительности среды пользователей.

VMware не только внесла значительные улучшения в ESA в vSAN 8 U1 и vSAN 8 U2, но и улучшила совместимость с оборудованием, предоставляя клиентам и партнерам простой и гибкий путь для создания поддерживаемой конфигурации. Давайте посмотрим, что поддерживается на данный момент.

Гибкость программы ReadyNode

Благодаря расширенной совместимости с устройствами хранения данных с интенсивным чтением и введению новых готовых узлов vSAN-ESA-AF-0 для небольших датацентров и периферийных сред, тип оборудования, совместимый с ESA, становится более гибким. vSAN ReadyNodes могут быть приобретены с использованием простого, единого SKU, но конфигурации, соответствующие vSAN ESA, также могут быть получены путем "эмуляции" конфигурации ReadyNode с использованием отдельных компонентов оборудования от сертифицированных поставщиков ReadyNode.

Это означает, что клиенты могут выбрать платформу сертифицированную по программе ESA ReadyNode от производителя серверов, указанную в VMware Compatibility Guide (VCG) for vSAN ESA, и далее могут создавать конфигурацию сервера с использованием отдельных аппаратных компонентов, как они указаны в данной спецификации ReadyNode, эмулируя реальный узел ReadyNode, приобретенный с использованием единого SKU. Этот подход может помочь клиентам, которые решили не покупать ReadyNode через официальный SKU, но имеют такое же оборудование (или лучше), найденное в желаемой классификации ReadyNode.

Термин «Emulated ReadyNode» просто относится к тому, из каких компонентов был собран готовый узел ReadyNode. Он воспринимается и поддерживается VMware и поставщиками ReadyNode точно так же, как узлы ReadyNodes, приобретенные с использованием единого SKU.

Поддержка таких эмулированных систем ReadyNode предоставляет большую гибкость при закупке оборудования и развертывании серверов, которые могут работать на vSAN ESA. Этот вариант применяется только к оборудованию и платформам, сертифицированным для ESA, а не к стандартному оборудованию серверов от производителей, не входящих в список ReadyNode. Тип подхода "собери сам" доступен только при использовании оригинальной архитектуры хранения vSAN (Original Storage Architecture, OSA).

Ну а в статье KB 90343 рассказано о том, что вы можете и не можете менять в конфигурации узлов для vSAN ESA ReadyNode:

Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров VMware vSAN 8 Update 2, а также о доступности его для загрузки. Также мы подробно рассказывали об одной из главных возможностей - расширении размера общих дисков VMware vSphere в кластерных приложениях на базе томов vVols без остановки системы.

Сегодня мы расскажем еще о некоторых функциях раздела Core Storage, которые появились в VMware vSAN 8 U2:

• Поддержка расширения диска vVols в режиме онлайн с Oracle RAC

В этом выпуске, помимо MS WSFC, была добавлена поддержка горячего расширения для дисков Oracle RAC, используя режим Multi-writer. Это можно выполнить как на дисках SCSI, так и на дисках NVMe vVols. Кроме того, это также позволяет клиентам переходить с томов RDM на новые хранилища.

• vVols NVMe миграция в режиме in-band

Поддержка миграции пространств имен NVMe vVol между группами ANA. Эта функциональность обеспечивает эквивалентность примитиву перепривязки SCSI и позволяет администратору хранилища балансировать нагрузки IO между устройствами PE.

• Автоматическое восстановление из статуса PDL для vVol PEs

Ранее, когда PE переходил в состояние PDL (Physical Device Loss) и затем возвращался, стек PSA должен был перезагрузить устройство (уничтожить и снова обнаружить пути). Это могло произойти только после того, как объекты vVol, использующие PE, были закрыты. С этим релизом, виртуальная машина будет автоматически выключена, когда обнаруживается, что PE, к которому привязаны vVols виртуальной машины, находится в состоянии PDL. Это дополнительно повышает устойчивость и восстановление при определенных сбоях подсистемы хранения.

• Включение поддержки MPP сторонних производителей для NVMe vVols

Позволяет сторонним политикам многопутевого доступа (MPP) поддерживать NVMe vVols. Это дает возможность партнерам VMware использовать свои клиентские MPP.

• Поддержка UNMAP для конфигурационного vVol

Начиная с vSphere 8.0 U1, конфигурационные vVols теперь создаются как тонкие диски с максимальным размером 255 ГБ и форматируются в VMFS-6. В этом релизе поддерживается командная строка (esxcli) для работы с командой unmap конфигурационных vVols.

Компания VMware объявила о том, что ее флагманская платформа виртуализации vSphere 8 Update 2 и решение для создания отказоустойчивых кластеров vSAN 8 Update 2, анонсированные ранее в рамках конференции Explore 2023, стали доступны для скачивания в рамках фазы Initial Availability (напомним, что для vCenter Server это фаза General Availability).

Вот основная ссылка для загрузки всех компонентов VMware vSphere.

Для скачивания VMware vSAN 8 Update 2 используйте вот эту ссылку. Обратите также внимание на красное предупреждение вверху:

Компания VMware опубликовала интересное техническое видео с обзором всех новых возможностей средства создания отказоустойчивых хранилищ vSAN 8 Update 2, работающих на базе обновленной платформы виртуализации vSphere 8 Update 2.

Видео длится 25 минут и покрывает все технические аспекты новых функций платформы, включая новую архитектуру vSAN Max, о которой рассказывается во всех подробностях.

Напомним также, что ранее VMware опубликовала еще одно полезное видео о новых возможностях vSphere 8 Update 2:

Ну и, конечно, нельзя не напомнить об этой ссылке на хранилище технических статей и документов о платформе VMware vSAN.

Продолжаем рассказ об анонсах новых продуктов и технологий, сделанных на прошедшей в конце августа конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

На прошлой неделе мы рассказали о новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 2, а сегодня поговорим о нововведениях решения для создания отказоустойчивых кластеров VMware vSAN 8 Update 2, а также недавно анонсированном решении VMware vSAN Max.

Продолжая свои начинания по поддержке наиболее критически важных рабочих нагрузок клиентов в плане гибкости, производительности и эффективности, VMware представляет vSAN 8 Update 2 и VMware vSAN Max.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволит получить модель развертывания на базе подписки для разрозненных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max, пользователи смогут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max будет лицензировано отдельно от существующих версий vSAN. vSAN Max будет предлагаться по подписке и, как планируется, будет лицензирован по метрике на тебибайт (TiB, близко к терабайту).

Кроме нового vSAN Max, улучшения в архитектуре vSAN Express Storage обеспечат новые уровни производительности, а новые функции на платформе vSAN улучшат повседневные операции и пользовательский опыт.

1. Объединенное хранилище масштабов петабайтов

Организации сегодня полагаются на множество приложений для ведения бизнеса, каждое из которых имеет уникальные требования к вычислительной мощности, объему хранения и производительности. Все чаще используются передовые аналитические инструменты, приложения ИИ и приложения, созданные изначально для облачных сервисов, в то время как реляционные базы данных и виртуальные рабочие столы по-прежнему остаются востребованными. Растущее разнообразие рабочих нагрузок и их динамика масштабирования создает потребность в гибкой инфраструктуре, которая позволяет этим критически важным приложениям масштабироваться по мере роста потребностей бизнеса.

С введением vSAN Max клиенты получат больший выбор для развертывания vSAN тем способом, который максимально оптимизирует использование ресурсов и снижает затраты. vSAN Max даст уникальную возможность настраивать кластер vSAN для использования в качестве общего хранилища для кластеров vSphere. Он создан на основе vSAN ESA и дает новые преимущества для клиентов, желающих быстро масштабировать хранилище с высокой производительностью и надежностью. vSAN Max предоставит беспрецедентные уровни масштабируемости и экономической эффективности, повышая отдачу при запуске нагрузок с интенсивным использованием хранилища на гиперконвергентной инфраструктуре (HCI), оптимизируя использование ресурсов и снижая TCO до 30%.

Применяя возможности горизонтального и вертикального масштабирования, пользователи будут иметь полную автономию в том, как увеличивать емкость. Узлы vSAN Max будут предлагать до 7 раз больше плотности, чем узлы HCI, и смогут масштабироваться до более чем 8.5 петабайта в кластере. Клиенты не только смогут масштабировать емкость, но и производительность; каждый добавленный узел в кластер vSAN Max увеличит доступную производительность. И поскольку vSAN Max создан на архитектуре vSAN Express Storage, он может вместить огромные наборы данных и соответствовать строгим требованиям к производительности и надежности, предоставляя до 3,6 миллиона IOPS на кластер хранилищ.

Как и всегда с vSAN, пользователи смогут управлять всеми средами - как традиционной моделью HCI, так и разобщенной моделью Max - из единого интерфейса.

2. Платформа высокой производительности

vSAN 8 U2 вводит несколько улучшений основной платформы, которые обеспечивают совершенно новые уровни производительности, долговечности данных и надежности в архитектуре Express Storage.

• Интегрированные файловые службы (Integrated File Services) для Cloud Native и традиционных рабочих нагрузок

vSAN 8 U2 добавляет файловые сервисы vSAN в архитектуру Express Storage. Клиенты получат преимущества в производительности и эффективности vSAN ESA для своих сред, использующих файловые сервисы vSAN. Все возможности, присутствующие в файловых сервисах vSAN на оригинальной архитектуре хранения (OSA) в предыдущих версиях vSAN, будут расширены для файловых сервисов vSAN на ESA: улучшенная эффективность использования пространства; лучшая производительность; и меньшие домены отказов.

• Улучшенная производительность для разобщенных сред (Disaggregated Environments)

vSAN 8 U1 представил новый адаптивный путь записи на архитектуре Express Storage с целью улучшения производительности для рабочих нагрузок, которые выполняли большое количество записей с высокой частотой, чтобы записать данные альтернативным, оптимизированным способом. Теперь это улучшение имплементировали в разобщенные топологии vSAN 8 U2 с vSAN Max. Теперь ВМ, работающие в кластере vSphere или vSAN и использующие ресурсы хранения другого кластера vSAN ESA или кластера vSAN Max, также смогут использовать эту возможность.

• Внедрение преимуществ vSAN ESA для малых дата-центров и Edge-локаций

vSAN 8 U2 вводит два новых улучшения, которые предоставят гораздо больше гибкости для клиентов, заинтересованных в использовании архитектуры ESA. Во-первых, это введение нового профиля ReadyNode — AF-0 ReadyNode, предназначенного для малых дата-центров и периферийных сред (Edge). Благодаря более низким требованиям к оборудованию, таким как 10Gb NICs, это означает, что клиенты смогут получать преимущества vSAN ESA в средах, которые не требуют производительности, предоставляемой более высокими профилями ReadyNode. Во-вторых, это введение поддержки устройств хранения с меньшим ресурсом записи, "Ready-Intensive". Эти устройства с меньшим ресурсом могут использоваться во многих профилях ReadyNode и предложат более выгодную цену для сред, которые, возможно, не имеют приложений с интенсивными операциями ввода/вывода.

3. Улучшенная управляемость

Производительность, устойчивость и гибкость теряют свой смысл, если решение сложно в эксплуатации. vSAN 8 U2 предлагает несколько новых улучшений, которые упростят повседневные операции администраторов, оптимизируют обнаружение проблем и ускорят время их решения.

• Интеллектуальная стандартная политика упрощает оптимальную конфигурацию

В vSAN 8 U1 появилась новая функция автоматического управления политиками, которая помогает администраторам настраивать свои новые кластеры vSAN ESA с оптимальными уровнями устойчивости и эффективности. В vSAN 8 U2 эта функция стала еще более мощной. При добавлении или удалении хоста из существующего кластера функция автоматического управления политиками будет оценивать, нужно ли корректировать оптимизированную стандартную политику хранения. Если vSAN определяет необходимость изменения, он позволяет изменить затронутую политику хранения одной кнопкой, которая появится в инициированной проверке health-статуса. В этом случае будет переконфигурирована стандартная политика хранения для кластера с новыми оптимизированными настройками политики.

• Отчетность о мощности кластера стала более понятной

В vSAN 8 U2 улучшена отчетность о накладных расходах на емкость для объектов, расположенных в хранилищах данных. Эта новая категория "ESA object overhead" (накладные расходы объекта ESA), размещенная в разделе "Usage breakdown" capacity-дэшборда кластера, сообщает о накладных расходах, связанных с обработкой и хранением данных через лог-структурированную файловую систему vSAN (vSAN LFS). Это улучшение поможет администраторам точнее определить накладные расходы по потреблению емкости в их системе хранения.

• Управление устройствами хранения в большом масштабе

Новая возможность prescriptive disk claim в vSAN ESA позволяет администраторам определять стандартизированный результат требований хостов, входящих в кластер, к диску с точки зрения емкости. vSAN затем попытается применить это желаемое состояние ко всем хостам в кластере. Если он не может применить конфигурацию, будет запущено определение состояния здоровья в Skyline Health для vSAN.

• Улучшенная безопасность через усовершенствованное управление ключами

Поскольку возможности безопасности инфраструктуры продолжают становиться более сложными, vSAN продолжает адаптироваться под поддержку этих новых возможностей. vSAN 8 U2 поддерживает применение серверов KMS, которые используют атрибут "key expiration" для назначения даты истечения ключа шифрования (Key Encryption Key, KEK). Интеграция с Skyline Health для vSAN будет инициировать отчет о состоянии здоровья при приближении сроков истечения ключа, упрощая управление.

• Интуитивное обнаружение ВМ и дисков, потребляющих больше всего ресурсов.

Представление "Top Contributors", появившееся в vSAN 7 U2, предоставляет простой способ определения ВМ, которые создают наибольший спрос на ресурсы, предоставляемые кластером. В vSAN 8 U2 инструмент стал еще лучше, помогая клиентам находить места с наибольшей производительностью не только в любой момент времени, но и в рамках настраиваемых периодов времени.

Администраторы также теперь смогут перемещать элементы в том же виде производительности — будь то IOPS, пропускная способность или задержка, что позволит им быстро оценить ВМ, создающие наибольшую нагрузку на кластер, и определить, не потребляют ли хосты кластера ресурсы непропорционально. Новое представление значительно упрощает устранение проблем с производительностью.

• Улучшенное обнаружение узких мест производительности в растянутых кластерах

vSAN I/O Trip Analyzer — это еще один инструмент, улучшенный в vSAN 8 U2, в нем появилась новая возможность проведения анализа рабочих нагрузок, работающих в растянутом кластере. Пользователь легко сможет определить, где в таком кластере происходит основная задержка, а также задержки в других частях стека, которые могут влиять на общую наблюдаемую ВМ задержку.

• Упрощенная конфигурация для 2-узловых и растянутых кластеров

vSAN 8 U2 упрощает конфигурацию растянутых кластеров и 2-узловых топологий. Администраторы могут помечать трафик vSAN Witness на виртуальном модуле Witness Appliance через настройки конфигурации VMkernel, а также удалять задачу тэгирования трафика Witness через командную строку. Также был увеличен размер Witness Appliance, доступного для vSAN ESA в vSAN 8 U2. В дополнение к размеру "large", клиенты, работающие с этими конфигурациями, также смогут выбрать модуль размера "medium", который потребляет 2 vCPU и 16GB RAM и поддерживает до 500 ВМ.

Решение VMware vSAN 8 Update 2 запланировано к выпуску в третьем квартале этого года. О новых возможностях платформы можно почитать тут, а вот здесь можно узнать про vSAN Max.

Вчера мы писали о том, какие результаты для производительности различных типов приложений дают новые функции в VMware vSAN 8 Update 1. Сегодня мы поговорим о том, как именно они реализованы.

Архитектура Express Storage Architecture (ESA) в vSAN 8 реализует новый способ обработки и хранения данных. Она предоставляет пользователям совершенно новые возможности, обеспечивает лучшую производительность и улучшает эффективность использования дискового пространства, при этом потребляя меньше ресурсов процессора.

В vSAN 8 U1 было представлено два новых, очень полезных улучшения для повышения производительности и эффективности обработки хранимых данных. Давайте рассмотрим это более подробно, чтобы понять, что это за улучшения, и при каких условиях они будут полезны.

1. Алгоритм VMware vSAN ESA Adaptive Write Path

Новый адаптивный путь записи в vSAN 8 U1 предоставляет ESA один из двух методов записи данных. Стандартный путь записи обрабатывает операции ввода-вывода (I/O) разных размеров, в то время как новый альтернативный путь записи оптимизирован для обработки больших I/O от гостевых ВМ. Зачем здесь два способа записи данных? Немного контекста поможет объяснить, почему это так важно.

Современные флэш-устройства предпочитают обрабатывать запись некоторого минимального объема данных. Это помогает уменьшить износ и активности по сбору мусора на устройствах. vSAN ESA была специально разработана для записи блоков данных, оптимально подходящих для этих устройств. Однако ESA также записывает данные эффективным образом с использованием минимального количества усилий. Для достижения этого используется кодирование RAID-5/6, где данные записываются в полные полосы (full stripe writes). Такие записи избегают шагов чтение-модификация-запись, часто связанных с записью данных с использованием erasure codes.

К сожалению, ВМ не всегда записывают данные большими блоками. Часто они обновляют только небольшие объемы данных. Учитывая это, ESA использует журналируемую (log-structured) файловую систему для объединения входящих операций ввода-вывода и сохранения данных и метаданных в журнал, чтобы можно было отправить подтверждение записи как можно быстрее. Это обеспечивает низкую и стабильную задержку для ВМ. Ну а данные из журнала записываются полной полосой (full stripe) позже. Это представляет собой стандартный путь записи (default write path), который был реализован в ESA на платформе vSAN 8.

Однако ВМ часто могут выполнять и крупные записи. Именно адаптивный путь записи в vSAN 8 U1 помогает записывать данные в таких условиях оптимальным образом. Когда vSAN определяет ситуацию, когда идут записи с использованием больших размеров I/O или большого количества ожидающих I/O, он будет использовать новый путь записи для больших I/O.

ESA в vSAN 8 U1 фиксирует эти I/O из буфера в памяти как полную полосу записи (full stripe) и записывает только метаданные в журналируемую файловую систему. Подтверждение записи будет отправлено ВМ, когда данные будут записаны напрямую в полную полосу записи на диск, а метаданные - в устойчивый журнал (durable log). Несмотря на то что основные данные обходят durable log, очень небольшое количество метаданных все же записывается для избыточности на двойное или тройное зеркало (в зависимости от назначенной политики хранения), чтобы гарантировать надежное хранение блоков.

Этот процесс принятия решений vSAN происходит в реальном времени для каждого объекта. В нем предусмотрены механизмы, помогающие определить, соответствуют ли последующие I/O критериям этого пути записи для больших I/O (это происходит в течение нескольких микросекунд) и вернуться к стандартному пути записи, если это не так.

Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

2. Оптимизированный процессинг операций ввода-вывода для отдельных объектов VMDK

vSAN ESA улучшает путь данных в стеке обработки таким образом, что позволяет ВМ обрабатывать операции ввода-вывода на новых уровнях. Это не только позволяет быстрее записывать и читать данные, но также помогает инженерным командам VMware выявить новые области в стеке для оптимизации, чтобы еще больше увеличить производительность. Процессы внутри программного обеспечения часто написаны с учетом определенных пределов оборудования и других процессов в стеке. С появлением новых аппаратных технологических решений эти процессы должны быть написаны так, чтобы использовать этот новый потенциал производительности.

vSAN 8 U1 вводит дополнительные вспомогательные потоки в распределенном менеджере объектов - слое стека vSAN, который отвечает за координацию и обработку операции ввода-вывода к объекту. Эти вспомогательные потоки помогают распределять усилия между большим количеством ядер процессора и помогают уменьшить истощение ресурсов процессора, если отдельный процесс перегружен.

Это увеличение параллелизма будет наиболее заметным на ресурсоемких ВМ, обрабатывающих большое количество I/O на VMDK, которые ранее были ограничены стеком каким-либо образом. Будь то критически важные приложения или системы с интенсивной транзакционной активностью, пользователи смогут увидеть улучшение производительности IOPS и пропускной способности до 25%.

Внутренние тесты VMware показали, что это улучшение позитивно скажется на различных типах рабочих нагрузок, включая ВМ, осуществляющие большие последовательные записи, а также мелкие случайные чтения. Даже когда рабочие нагрузки не получают прямой выгоды от этой функции, может быть второй порядок выгоды, где сокращение конкурирующих процессов и ресурсов позволит другим несвязанным действиям, использующим те же общие ресурсы, завершить свои процессы быстрее.

В начале этого года компания VMware выпустила значимое обновление решения vSAN 8 Update 1, где было заявлено достаточно много улучшений в сфере производительности, особенно для архитектуры vSAN ESA (например, Adaptive Write Path).

Сегодня мы посмотрим на то, как эти улучшения в действительности влияют на разные типы приложений в рамках архитектуры кластеров Express Storage Architecture.

1. Приложения для видеонаблюдения

Эти типы решений часто генерируют большие объемы последовательных записей, которые для системы хранения могут быть одним из наиболее требовательных типов профилей рабочей нагрузки, потому что записывается большое количество данных с использованием больших размеров операций ввода-вывода (I/O). При сравнении производительности с OSA (Original Storage Architecture) в VMware обнаружили, что ESA предоставляет улучшение производительности до 240%. То есть вы можете увеличить обмен I/O более чем в три раза, используя то же самое оборудование! Это улучшение демонстрирует возможности нового алгоритма Adaptive Write Path, добавленного в vSAN 8 U1, который может определить, когда происходят такие операции записи, и использовать наиболее оптимальный путь записи для этих условий.

2. Сервисы Apache Kafka

Характеристики потока ввода-вывода Apache Kafka имеют некоторые сходства с приложениями для видеотрансляции, где они могут предъявлять высокие требования к системе хранения. Распределенные решения для потоковой передачи событий, такие как Kafka, были разработаны для удобного масштабирования, и в зависимости от конфигурации, могут генерировать очень большие объемы данных для непрерывной записи. При проведении сравнительных тестов в VMware обнаружили, что ESA обеспечивает улучшение производительности до 80% при работе с Kafka. И это также демонстрирует, насколько хорошо ESA справляется с рабочими нагрузками, генерирующими плотный поток записи.

3. Приложения в сфере здравоохранения

Продукты, использующие реляционные базы данных, являются основой многих приложений в широком спектре отраслей. Отрасль здравоохранения в большой степени зависит от решений Electronic Health Records (EHR), чтобы обеспечивать наилучший уход за пациентами, что является ярким примером "критически важных" приложений. vSAN всегда была идеальной платформой для среды здравоохранения, и с появлением ESA она стала еще лучше. Тесты VMware показали, что эти зависящие от баз данных медицинские приложения предлагают до 50% лучшую производительность при работе на платформе ESA. Это впечатляющий уровень улучшений, учитывая высокую транзакционную природу этих приложений.

4. NoSQL приложения

Некоторые решения используют нереляционную базу данных NoSQL для хранения данных своих приложений. NoSQL может просто масштабироваться и часто используется в ряде открытых и коммерческих приложений. В VMware обнаружили, что приложения на основе NoSQL работают на 15% быстрее с использованием ESA. Это довольно значимо, учитывая что процессор, память и сетевая задержка часто являются наиболее распространенными препятствиями для производительности в среде NoSQL.

Хотя показатели производительности ESA весьма впечатляющи, учитывая постоянные улучшения производительности, внесенные в vSAN OSA, есть и второстепенные преимущества ESA, которыми не следует пренебрегать.

• Эффективное использование ресурсов. ESA потребляет меньше аппаратных ресурсов для обработки и хранения данных. Это означает, что в сравнении с OSA вам, возможно, понадобится меньше хостов для удовлетворения тех же требований к рабочей нагрузке, или вы сможете запускать больше рабочих нагрузок на том же объеме оборудования. Оба варианта эффективно снижают затраты на владение виртуальной средой.
• Повышенная стабильность и производительность. Более эффективный стек хранения уменьшает спрос на физические ресурсы, такие как процессор, и может помочь повысить стабильность уровня производительности, предоставляемого гостевым ВМ. Это может быть особенно важно для систем, которые являются критически важными и которые должны иметь не только низкий уровень задержек, но и стабильность в плане производительности.
• Лучшая эффективность использования пространства. vSAN ESA предлагает улучшенную эффективность использования пространства без компромиссов. В отличие от OSA, он может надежно хранить данные с использованием кодирования RAID-5/6 при производительности на уровне RAID-1. Это обеспечивает гарантированную эффективность использования пространства при надежном хранении данных. ESA также может сжимать данные с минимальным использованием ресурсов и даже уменьшать использование пропускной способности канала.
• Проще в управлении. Идея "производительности без компромиссов" также улучшает управление. Рекомендации по оптимизации для достижения наилучшей возможной производительности стали проще с vSAN ESA (подробнее об этом рассказано тут).

На этом пока все, ну а завтра мы расскажем, собственно, о самом механизме Adaptive Write Path и других нововведениях VMware vSAN 8 Update 1.

Дункан Эппинг в своем блоге описал ситуацию, когда один из администраторов распределенного кластера vSAN увидел множество сообщений об ошибках, говорящих о том, что vSphere HA не мог перезапустить определенную виртуальную машину во время сбоя межсайтового соединения ISL.

Бывает это в следующей типовой конфигурации кластера vSAN:

Предположим, что Datacenter A - это "preferred site", а Datacenter B - это "secondary site". Если между датацентром A и датацентром B происходит сбой ISL, компонент Witness, находящийся на третьей площадке, автоматически привяжет себя к датацентру A. Это означает, что ВМ в датацентре B потеряют доступ к хранилищу данных vSAN.

С точки зрения кластера HA, у датацентра A всегда будет Primary-узел (ранее он назывался Master), он же есть и у датацентра B. Первичный узел обнаружит, что есть некоторые ВМ, которые больше не работают, и он попытается перезапустить их. Он попытается сделать это на обеих площадках, и конечно, сайт, где доступ к хранилищу данных vSAN потерян, увидит, что перезапуск не удался.

А вот и важный момент, в зависимости от того, где/как сервер vCenter подключен к этим площадкам. Он может получать, а может и нет информацию об успешных и неудачных перезапусках. Иногда бывают ситуации (в зависимости от архитектуры и характера сбоя), когда сервер vCenter может общаться только с primary-узлом в датацентре B, и это приводит к сообщениям о неудачных попытках перезапуска, хотя на самом деле все ВМ были успешно перезапущены в датацентре A.

В этом случае интерфейс может дать разъяснение - он даст вам информацию о том, какой узел является первичным, и также сообщит вам о либо об "изоляции сети" (network isolation) или о "разделении сети" (network partition) в соответствующих разделах разделах панели Hosts. При сбое ISL - это, конечно же, разделение сети.

На днях компания VMware сделала анонс большого обновления своей архитектуры VMware Cloud Foundation версии 5.0. Этот крупный релиз платформы предлагает дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

Основные компоненты VCF 5.0 выглядят следующим образом:

Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О прошлой версии этой платформы 4.5 мы писали вот тут.

Релиз VMware Cloud Foundation 5.0 является результатом многих месяцев разработки и тестирования. В этот период испытывались последние версии vSphere 8.0 Update 1a для управления рабочей нагрузкой, vSAN 8.0 Update 1a для масштабируемого хранения, NSX 4.1 для сетевых решений и vRealize Lifecycle Manager 8.10 (Aria) для управления облаками.

Давайте посмотрим, что новой в обновленной архитектуре VCF 5:

1. Улучшения SDDC Manager

VMware Cloud Foundation 5.0 включает новую функцию под названием Isolated SSO Workload Domains, которая позволяет администраторам настроить новые области рабочей нагрузки, используя отдельный экземпляр Single Sign On (SSO). Этот сценарий полезен для крупных предприятий, которым необходима изоляция рабочих нагрузок, а также для сервис-провайдеров, которые могут выделять области рабочей нагрузки различным клиентам с их собственными доменами SSO. В каждом изолированном домене SSO настраивается собственный экземпляр NSX. Дополнительное преимущество заключается в том, что настройка областей рабочей нагрузки как изолированной области рабочей нагрузки также дает возможность настроить и отдельного поставщика идентификации (Active Directory или LDAP).

2. Масштабирование области рабочей нагрузки

Для Workload domain scaling число изолированных областей рабочей нагрузки увеличено с 15 до 25 в рамках одного экземпляра VMware Cloud Foundation. Обратите внимание, что области рабочей нагрузки, настроенные на использование общего домена управления SSO, по-прежнему ограничены максимумом 15 доменов. Дополнительное масштабирование становится возможным благодаря параллелизации задач с целью уменьшения времени на добавление областей рабочей нагрузки в экземпляр VMware Cloud Foundation.

3. Улучшения платформы и масштабирования VMware Cloud Foundation

Если посмотреть на новые возможности, представленные в VMware Cloud Foundation 5.0, улучшения платформы vSphere / vSAN и масштабирования, являются самыми ожидаемыми запросами функций от клиентов сред VMware Cloud Foundation. Также важно подчеркнуть, что обновления до VMware Cloud Foundation 5.0 являются прямыми, с возможностью пропуска обновлений версий VMware Cloud Foundation 4.3, 4.4 и 4.5.

4. Проверки SDDC Manager Context Aware Pre-Checks и дрейф конфигурации (Configuration Drift)

Для обеспечения лучшего пользовательского опыта менеджер SDDC использует предварительные контекстные проверки (Pre-Checks), чтобы убедиться, что стек инфраструктуры готов принять желаемое обновление. Рабочие процессы, построенные в VMware Cloud Foundation 5.0, обеспечивают обновление развертывания до желаемой версии VMware Cloud Foundation в правильном порядке, начиная с компонентов домена управления.

В VMware Cloud Foundation 5.0 предварительные проверки менеджера SDDC были улучшены и теперь учитывают контекст. После того как менеджер SDDC был установлен или обновлен до версии 5.0, администраторы могут выбрать обновление своих доменов VMware Cloud Foundation до новой целевой версии VMware Cloud Foundation 5.x (при необходимости пропуская релизы), что дает администраторам возможность провести предварительную проверку для определенного релиза VMware Cloud Foundation или выполнить предварительную проверку "готовности к общему обновлению", чтобы обеспечить общую готовность платформы.

С VMware Cloud Foundation 5.0, менеджер SDDC также позволяет администраторам просматривать любые изменения в конфигурации, которые устанавливаются в рамках обновления, чтобы обеспечить дополнительную видимость и помочь администраторам лучше понять новые функции и возможности, а также влияние, которое они могут оказать на их текущие развертывания.

Более подробно о новых возможностях VMware Cloud Foundation 5.0 также можно почитать в следующих статьях:

• Announcing VMware Cloud Foundation 5.0
• What’s New with vSphere and vSAN in VCF 5.0
• What’s New with NSX in VMware Cloud Foundation 5.0
• What’s New with vRealize Suite in VMware Cloud Foundation 5.0
• VMware Cloud Foundation 5.0 Release Notes

Дункан Эппинг опубликовал интересную статью, касающуюся проблем, возникающих в растянутом кластере VMware vSAN при различных сценариях отказов в нем.

В некоторых из приведенных ниже сценариев Дункан обсуждает сценарии разделения кластера. Под разделением подразумевается ситуация, когда и L3-соединение с компонентом Witness, и ISL-соединение с другим сайтом недоступны для одного из сайтов. Так, на примере приведенной выше диаграммы, если говорится, что сайт B изолирован - это означает, что сайт A все еще может общаться со свидетелем, но сайт B не может общаться ни со свидетелем, ни с сайтом A.

Во всех следующих сценариях действуют следующие условия: сайт A является предпочтительным местоположением, а сайт B - второстепенным. Что касается таблицы ниже, то первые два столбца относятся к настройке политики для виртуальной машины, как показано на скриншоте:

Третий столбец относится к местоположению, откуда виртуальная машина работает с точки зрения вычислительных ресурсов (хоста ESXi). Четвертый описывает тип сбоя, а пятый и шестой столбцы детализируют наблюдаемое в этом случае поведение.

На сайте проекта VMware Labs вышло очередное обновление утилиты vSAN Objects Viewer 1.5.7, которая позволяет выводить информацию о различных компонентах vSAN в целях анализа конфигураций и хранилищ.

При устранении проблем с vSAN, анализ вывода команды cmmds-tools и локальных команд является важным для получения полного представления о среде vSAN. Такая информация включает информацию о кластере vSAN, узлах, группах дисков и объектах. Однако ручной процесс анализа может быть затратным по времени. Чтобы сэкономить время и усилия, VMware разработала инструмент, который быстро преобразует информацию о vSAN из текста в графику, включая:

• Топологию кластера vSAN
• Информацию об узлах vSAN
• Информацию о группах дисков vSAN
• Состав ВМ и объектов
• Распределение и статус компонентов

По сравнению с существующими анализаторами, данный инструмент выводит больше деталей о vSAN DOM и LSOM, таких как тип и распределение статусов, выходя за рамки информации об аппаратном обеспечении и углубляясь в объекты DOM. vSAN Objects Viewer имеет три основные функции:

• Отображение информации о состоянии здоровья кластера vSAN
• Показ информации о ВМ и объектах
• Визуализация распределения объектов

Скачать vSAN Objects Viewer 1.5.7 можно по этой ссылке.

На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.

В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.

Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):

В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:

1. Масштабирование распределенных хранилищ

Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.

• Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage

В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.

• Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA

В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.

• Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server

vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).

2. Улучшение платформы

• Улучшенная производительность с использованием нового адаптивного пути записи

В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.

• Улучшенная производительность для отдельных нагрузок

Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.

• Улучшенная надежность во время сценариев режима обслуживания.

В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.

• Улучшения управления датасторами

В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.

3. Упрощение управления

При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.

• Автоматическое управление политиками для Default Storage Policies (ESA)

В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.

• Skyline Health Score и исправление конфигурации

В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".

С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).

• Более высокий уровень детализации для улучшенного анализа производительности

Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.

• Упрощенный сбор диагностической информации о производительности

В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.

• Новая интеграция PowerCLI

В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.

4. Функции Cloud Native Storage

Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.

• Поддержка CNS для vSAN ESA

В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.

• Поддержка DPp общих виртуальных коммутаторов

vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.

• Развертывние Thick provisioning для vSAN Direct Configuration

Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).

Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.

Недавно мы писали об анонсированных новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 1, выход которой ожидается в ближайшее время. Параллельно с этим компания VMware объявила и о выпуске новой версии решения VMware vSAN 8 Update 1, предназначенного для создания высокопроизводительных отказоустойчивых хранилищ для виртуальных машин, а также об улучшениях подсистемы хранения Core Storage в обеих платформах.

Недавно компания VMware также выпустила большую техническую статью "What's New with vSphere 8 Core Storage", в которой детально рассмотрены все основные новые функции хранилищ, с которыми работают платформы vSphere и vSAN. Мы решили перевести ее с помощью ChatGPT и дальше немного поправить вручную. Давайте посмотрим, что из этого вышло :)

Итак что нового в части Core Storage платформы vSphere 8 Update 1

Одно из главных улучшений - это новая система управления сертификатами. Она упрощает возможность регистрации нескольких vCenter в одном VASA-провайдере. Это положит основу для некоторых будущих возможностей, таких как vVols vMSC. Такж есть и функции, которые касаются масштабируемости и производительности. Поскольку vVols могут масштабироваться гораздо лучше, чем традиционное хранилище, VMware улучшила подсистему хранения, чтобы тома vVols работали на больших масштабах.

1. Развертывание нескольких vCenter для VASA-провайдера без использования самоподписанных сертификатов

Новая спецификация VASA 5 была разработана для улучшения управления сертификатами vVols, что позволяет использовать самоподписанные сертификаты для многовендорных развертываний vCenter. Это решение также решает проблему управления сертификатами в случае, когда независимые развертывания vCenter, работающие с различными механизмами управления сертификатами, работают вместе. Например, один vCenter может использовать сторонний CA, а другой vCenter может использовать сертификат, подписанный VMCA. Такой тип развертывания может быть использован для общего развертывания VASA-провайдера. Эта новая возможность использует механизм Server Name Indication (SNI).

SNI - это расширение протокола Transport Layer Security (TLS), с помощью которого клиент указывает, какое имя хоста он пытается использовать в начале процесса handshake. Это позволяет серверу показывать несколько сертификатов на одном IP-адресе и TCP-порту. Следовательно, это позволяет обслуживать несколько безопасных (HTTPS) веб-сайтов (или других служб через TLS) с одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это является концептуальным эквивалентом виртуального хостинга на основе имени HTTP/1.1, но только для HTTPS. Также теперь прокси может перенаправлять трафик клиентов на правильный сервер во время хэндшейка TLS/SSL.

2. Новая спецификация vVols VASA 5.0 и некоторые детали функций

Некоторые новые функции, добавленные в vSphere 8 U1:

• Изоляция контейнеров - работает по-разному для поставщиков VASA от различных производителей. Она позволяет выполнять настройку политики контроля доступа на уровне каждого vCenter, а также дает возможность перемещения контейнеров между выбранными vCenter. Это дает лучшую изоляцию на уровне контейнеров, а VASA Provider может управлять правами доступа для контейнера на уровне каждого vCenter.
• Аптайм - поддержка оповещений об изменении сертификата в рамках рабочего процесса VASA 5.0, который позволяет обновлять сертификат VMCA в системах с несколькими vCenter. Недействительный или истекший сертификат вызывает простой, также возможно возникновение простоя при попытке регистрации нескольких vCenter с одним VASA Provider. В конфигурации с несколькими vCenter сертификаты теперь можно обновлять без простоя.
• Улучшенная безопасность для общих сред - эта функция работает по-разному для поставщиков VASA от производителей. Все операции могут быть аутентифицированы в контексте vCenter, и каждый vCenter имеет свой список контроля доступа (ACL). Теперь нет самоподписанных сертификатов в доверенном хранилище. VASA Provider может использоваться в облачной среде, и для этого также есть доступная роль в VASA 5.0.
• Обратная совместимость - сервер ESXi, который поддерживает VASA 5.0, может решать проблемы с самоподписанными сертификатами и простоями, возникающими в случае проблем. VASA 5.0 остается обратно совместимым и дает возможность контролировать обновление в соответствии с требованиями безопасности. VASA 5.0 может сосуществовать с более ранними версиями, если производитель поддерживает эту опцию.
• Гетерогенная конфигурация сертификатов - работает по-разному для поставщиков VASA от производителей. Теперь используется только подписанный сертификат VMCA, дополнительный CA не требуется. Это позволяет изолировать доверенный домен vSphere. VASA 5.0 позволяет использовать разные конфигурации для каждого vCenter (например, Self-Managed 3rd Party CA Signed Certificate и VMCA managed Certificate).
• Не необходимости вмешательства администратора - поддержка многократного развертывания vCenter с использованием VMCA, которая не требует от пользователя установки и управления сертификатами для VP. Служба SMS будет отвечать за предоставление сертификатов. Теперь это работает в режиме Plug and Play с автоматической предоставлением сертификатов, без вмешательства пользователя, при этом не требуется никаких ручных действий для использования VASA Provider с любым vCenter.
• Комплаенс безопасности - отсутствие самоподписанных сертификатов в доверенных корневых центрах сертификации позволяет решить проблемы соответствия требованиям безопасности. Не-СА сертификаты больше не являются частью хранилища доверенных сертификатов vSphere. VASA 5.0 требует от VASA Provider использовать сертификат, подписанный СА для связи с VASA.

3. Перенос Sidecar vVols в config-vvol вместо другого объекта vVol

Sidecars vVols работали как объекты vVol, что приводило к накладным расходам на операции VASA, такие как bind/unbind. Решения, такие как First Class Disks (FCD), создают большое количество маленьких sidecars, что может ухудшить производительность vVols. Кроме того, поскольку может быть создано множество sidecars, это может учитываться в общем количестве объектов vVol, поддерживаемых на массиве хранения. Чтобы улучшить производительность и масштабируемость, теперь они обрабатываются как файлы на томе config-vvol, где могут выполняться обычные операции с файлами. Не забывайте, что в vSphere 8 был обновлен способ байндига config-vvol. В результате, с новым механизмом config-vvol уменьшается число операций и задержки, что улучшает производительность и масштабируемость.

Для этой функциональности в этом релизе есть несколько ограничений при создании ВМ. Старые виртуальные машины могут работать в новом формате на обновленных до U1 хостах, но сам новый формат не будет работать на старых ESXi. То есть новые созданные ВМ и виртуальные диски не будут поддерживаться на хостах ниже версии ESXi 8 U1.

5. Улучшения Config-vvol, поддержка VMFS6 config-vvol с SCSI vVols (вместо VMFS5)

Ранее Config-vvol, который выступает в качестве каталога для хранилища данных vVols и содержимого VM home, был ограничен размером 4 ГБ. Это не давало возможности использования папок с хранилищем данных vVols в качестве репозиториев ВМ и других объектов. Для преодоления этого ограничения Config-vvol теперь создается как тонкий объект объемом 255 ГБ. Кроме того, вместо VMFS-5 для этих объектов будет использоваться формат VMFS-6. Это позволит размещать файлы sidecar, другие файлы VM и библиотеки контента в Config-vvol.

На изображении ниже показаны Config-vvol разных размеров. Для машины Win10-5 Config-vvol использует исходный формат 4 ГБ, а ВМ Win10-vVol-8u1 использует новый формат Config-vvol объемом 255 ГБ.

6. Добавлена поддержка NVMe-TCP для vVols

В vSphere 8 была добавлена поддержка NVMe-FC для vVols. В vSphere 8 U1 также расширена поддержка NVMe-TCP, что обеспечивает совместное использование NVMeoF и vVols. См. статью vVols with NVMe - A Perfect Match | VMware.

7. Улучшения NVMeoF, PSA, HPP

Инфраструктура поддержки NVMe end-to-end:

Расширение возможностей NVMe дает возможность поддержки полного стека NVMe без какой-либо трансляции команд SCSI в NVMe на любом уровне ESXi. Еще одной важной задачей при поддержке end-to-end NVMe является возможность контроля multipath-плагинов сторонних производителей для управления массивами NVMe.

Теперь с поддержкой GOS протокол NVMe может использоваться для всего пути - от GOS до конечного таргета.

Важным аспектом реализации VMware трансляции хранилищ виртуальных машин является поддержка полной обратной совместимости. VMware реализовала такой механизм, что при любом сочетании виртуальных машин, использующих SCSI или контроллер vNVMe, и целевого устройства, являющегося SCSI или NVMe, можно транслировать путь в стеке хранения. Это дизайн, который позволяет клиентам переходить между SCSI- и NVMe-хранилищами без необходимости изменения контроллера хранилищ для виртуальной машины. Аналогично, если виртуальная машина имеет контроллер SCSI или vNVMe, он будет работать как на SCSI-, так и на NVMeoF-хранилищах.

Упрощенная диаграмма стека хранения выглядит так:

Для получения дополнительной информации о NVMeoF для vSphere, обратитесь к странице ресурсов NVMeoF.

8. Увеличение максимального количества путей для пространств имен NVMe-oF с 8 до 32

Увеличение количества путей улучшает масштабирование в окружениях с несколькими путями к пространствам имен NVMe. Это необходимо в случаях, когда хосты имеют несколько портов и модуль имеет несколько нод, а также несколько портов на одной ноде.

9. Увеличение максимального количества кластеров WSFC на один хост ESXi с 3 до 16

Это позволяет уменьшить количество лицензий Microsoft WSFC, необходимых для увеличения количества кластеров, которые могут работать на одном хосте.

Для получения дополнительной информации о работе Microsoft WSFC на vSphere можно обратиться к следующим ресурсам:

• О настройке кластеров отказоустойчивости Windows Server на VMware vSphere
• Начало работы с WSFC на VMware vSphere
• Требования к оборудованию и программному обеспечению для WSFC на vSphere
• Кластер отказоустойчивости Microsoft Windows Server (WSFC) с общими дисками на VMware vSphere 8.x: Рекомендации по поддерживаемым конфигурациям (89327)
• Кластер отказоустойчивости Microsoft Windows Server (WSFC) с общими дисками на VMware vSphere 7.x: Рекомендации по поддерживаемым конфигурациям (79616)

10. Улучшения VMFS - расширенная поддержка XCOPY для копирования содержимого датасторов между различными массивами

ESXi теперь поддерживает расширенные функции XCOPY, что оптимизирует копирование данных между датасторами разных массивов. Это поможет клиентам передать обработку рабочих нагрузок на сторону хранилища. Функция уже доступна в vSphere 8 U1, но по факту миграция данных между массивами должна поддерживаться на стороне хранилища.

11. Реализация NFSv3 vmkPortBinding

Данная функция позволяет привязать соединение NFS для тома к конкретному vmkernel. Это помогает обеспечить безопасность, направляя трафик NFS по выделенной подсети/VLAN, и гарантирует, что трафик NFS не будет использовать mgmt-интерфейс или другие интерфейсы vmkernel.

Предыдущие монтирования NFS не содержат этих значений, хранящихся в config store. Во время обновления, при чтении конфигурации из конфигурационного хранилища, значения vmknic и bindTovmnic, если они есть, будут считаны. Поэтому обновления с предыдущих версий не будут содержать этих значений, так как они являются необязательными.

12. Улучшения VM Swap

Здесь появились следующие улучшения:

• Увеличена производительность включения/выключения ВМ
• Увеличена производительность vMotion

Изменения в способе создания/удаления Swap-файлов для томов vVols помогли улучшить производительность включения/выключения, а также производительность vMotion и svMotion.

13. Улучшения Config vVol и сохранение привязки

Здесь были сделаны следующие доработки:

• Уменьшено время запроса при получении информации о ВМ
• Добавлено кэширование атрибутов vVol - размер, имя и прочих

Конфигурационный vVol - это место, где хранятся домашние файлы виртуальной машины (vmx, nvram, logs и т. д.) и к нему обычно обращаются только при загрузке или изменении настроек виртуальной машины.

Ранее использовалась так называемая "ленивая отмена связи" (lazy unbind), и происходил unbind конфигурационного vVol, когда он не использовался. В некоторых случаях приложения все же периодически обращались к конфигурационному vVol, что требовало новой операции привязки. Теперь эта связь сохраняется, что уменьшает задержку при доступе к домашним данным виртуальной машины.

14. Поддержка NVMeoF для vVols

vVols были основным направлением развития функциональности хранилищ VMware в последние несколько версий, и для vSphere 8.0 это не исключение. Самое большое обновление в ядре хранения vSphere 8.0 - добавление поддержки vVols в NVMeoF. Изначально поддерживается только FC, но со временем будут работать и другие протоколы, провалидированные и поддерживаемые с помощью vSphere NVMeoF. Теперь есть новая спецификация vVols и VASA/VC-фреймворка - VASA 4.0/vVols 3.0.

Причина добавления поддержки vVols в NVMeoF в том, что многие производители массивов, а также отрасль в целом, переходят на использование или, по крайней мере, добавление поддержки NVMeoF для повышения производительности и пропускной способности. Вследствие этого VMware гарантирует, что технология vVols остается поддерживаемой для последних моделей хранилищ.

Еще одним преимуществом NVMeoF vVols является настройка. При развертывании после регистрации VASA фоновая установка завершается автоматически, вам нужно только создать датастор. Виртуальные эндпоинты (vPE) и соединения управляются со стороны VASA, что упрощает настройку.

Некоторые технические детали этой реализации:

• ANA Group (Асимметричный доступ к пространству имен)

С NVMeoF реализация vVols немного отличается. С традиционными SCSI vVols хранилищами контейнер является логической группировкой самих объектов vVol. С NVMeoF это варьируется в зависимости от того, как поставщик массива реализует функциональность. В общем и целом, на хранилище группа ANA является группировкой пространств имен vVol. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Пространства имен выделяются и активны только по запросу BIND к провайдеру VASA (VP). Пространства имен также добавляются в группу ANA при запросе BIND к VP. Пространство имен остается выделенным/активным до тех пор, пока последний хост не отвяжет vVol.

• vPE (virtual Protocol Endpoint)

Для традиционных vVols на базе SCSI, protocol endpoint (PE) - это физический LUN или том на массиве, который отображается в появляется в разделе устройств хранения на хостах. С NVMeoF больше нет физического PE, PE теперь является логическим объектом, представлением группы ANA, в которой находятся vVols. Фактически, до тех пор, пока ВМ не запущена, vPE не существует. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Как только ВМ запущена, создается vPE, чтобы хост мог получить доступ к vVols в группе ANA. На диаграмме ниже вы можете увидеть, что vPE указывает на группу ANA на массиве.

• NS (пространство имен, эквивалент LUN в NVMe)

Каждый тип vVol (Config, Swap, Data, Mem), созданный и использующийся машиной, создает NS, который находится в группе ANA. Это соотношение 1:1 между vVol и NS позволяет вендорам оборудования легко масштабировать объекты vVols. Обычно поставщики поддерживают тысячи, а иногда и сотни тысяч NS. Ограничения NS будут зависеть от модели массива.

На диаграмме вы можете увидеть, что сама виртуальная машина является NS, это будет Config vVol, а диск - это другой NS, Data vVol.

Вы можете узнать больше о технических деталях NVMe-FC и vVols в этой статье блога: "vVols with NVMe - A Perfect Match | VMware".

15. Улучшения NVMeoF

• Поддержка 256 пространств имен и 2K путей с NVMe-TCP и NVMe-FC

NVMeoF продолжает набирать популярность по очевидным причинам - более высокая производительность и пропускная способность по сравнению с традиционным подключением SCSI или NFS. Многие производители хранилищ также переходят на NVMe-массивы и использование SCSI для доступа к NVMe флэш-накопителям является узким местом и потенциалом для улучшений.

Продолжая работать на этим, VMware увеличила поддерживаемое количество пространств имен и путей как для NVMe-FC, так и для TCP.

• Расширение reservations для устройств NVMe

Добавлена поддержка команд reservations NVMe для использования таких решений, как WSFC. Это позволит клиентам использовать возможности кластеризованных дисков VMDK средствами Microsoft WSFC с хранилищами данных NVMeoF. Пока поддерживается только протокол FC.

• Поддержка автообнаружения для NVMe Discovery Service на ESXi

Расширенная поддержка NVMe-oF в ESXi позволяет динамически обнаруживать совместимые со стандартом службы NVMe Discovery Service. ESXi использует службу mDNS/DNS-SD для получения информации, такой как IP-адрес и номер порта активных служб обнаружения NVMe-oF в сети.

Также ESXi отправляет многоадресный DNS-запрос (mDNS), запрашивая информацию от сущностей, предоставляющих службу обнаружения DNS-SD. Если такая сущность активна в сети (на которую был отправлен запрос), она отправит (одноадресный) ответ на хост с запрошенной информацией - IP-адрес и номер порта, где работает служба.

16. Улучшение очистки дискового пространства с помощью Unmap

• Снижение минимальной скорости очистки до 10 МБ/с

Начиная с vSphere 6.7, была добавлена функция настройки скорости очистки (Unmap) на уровне хранилища данных. С помощью этого улучшения клиенты могут изменять скорость очистки на базе рекомендаций поставщика их массива. Более высокая скорость очистки позволяла многим пользователям быстро вернуть неиспользуемое дисковое пространство. Однако иногда даже при минимальной скорости очистки в 25 МБ/с она может быть слишком высокой и привести к проблемам при одновременной отправке команд Unmap несколькими хостами. Эти проблемы могут усугубляться при увеличении числа хостов на один датастор.

Пример возможной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с

Чтобы помочь клиентам в ситуациях, когда скорость очистки 25 МБ/с может приводить к проблемам, VMware снизила минимальную скорость до 10 МБ/с и сделала ее настраиваемой на уровне датасторов:

При необходимости вы также можете полностью отключить рекламацию пространства для заданного datastore.

• Очередь планирования отдельных команд Unmap

Отдельная очередь планирования команд Unmap позволяет выделить высокоприоритетные операции ввода-вывода метаданных VMFS и обслуживать их из отдельных очередей планирования, чтобы избежать задержки их исполнения из-за других команд Unmap.

17. Контейнерное хранилище CNS/CSI

Теперь вы можете выбрать политику Thin provisioning (EZT, LZT) через SPBM для CNS/Tanzu.

Цель этого - добавить возможность политик SPBM для механизма создания/изменения правил политик хранения, которые используются для параметров выделения томов. Это также облегчает проверку соответствия правил выделения томов в политиках хранения для SPBM.

• Операции, поддерживаемые для виртуальных дисков: создание, реконфигурация, клонирование и перемещение.
• Операции, поддерживаемые для FCD: создание, обновление политики хранения, клонирование и перемещение.

18. Улучшения NFS

Инженеры VMware всегда работают над улучшением надежности доступа к хранилищам. В vSphere 8 были добавлены следующие улучшения NFS, повышающие надежность:

• Повторные попытки монтирования NFS при сбое
• Валидация монтирования NFS

Ну как вам работа ChatGPT с правками человека? Читабельно? Напишите в комментариях!

Как знают многие администраторы, у VMware есть список сертифицированных конфигураций оборудования, подходящих под использование продуктов линейки vSAN (а также различных профилей нагрузки, например, VDI), который называется Ready Node.

Также, как вы помните, с релизом новой версии решения для создания отказоустойчивых кластеров хранилищ vSAN 8 компания VMware выпустила и новую архитектуру Express Storage Architecture (ESA). Это архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

С релизом ESA многие администраторы задались вопросом, на каких серверах можно развертывать сервисы этой архитектуры vSAN. С самого начала в списке Ready Node поддерживалось оборудование Dell, HPe и Lenovo, а недавно добавили и серверы Supermicro.

Основная модификация, которая, как правило, интересует пользователей - это "Storage Device" и "Number of Storage Devices", то есть возможность заменять тип накопителей и их количество. Но это не все - в зависимости от типов узлов вы можете менять CPU и память (только в сторону увеличения ресурсов), а также сетевые карты и их количество.

Полный список доступны изменений приведен в KB 90343, но их суть сводится к таблице, представленной ниже (кликните для увеличения):

В той же статье вы найдете и ответы на самые часто возникающие вопросы об узлах Ready Node для Express Storage Architecture.

Архитектура VMware HCI Mesh - два важных момента

Дункан Эппинг обратил внимание на два важных аспекта архитектуры VMware HCI Mesh, которая появилась в версии платформы VMware vSphere 7 Update 1. С помощью нее можно монтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.

В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.

Дункан справедливо отмечает - здесь можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером. То есть датасторы кластеров vSAN могут находиться в общем пространстве хранения для распределенных датацентров. Надо отметить, что многие пользователи применяют такой подход как альтернативу растянутым кластерам vSAN (stretched clusters):

Надо помнить, что при этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.

Второй важный момент: это архитектура ESA (Express Storage Architecture), появившаяся в VMware vSAN 8. Это новая архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Так вот, архитектура ESA не поддерживается для механизма HCI Mesh (по крайней мере, пока). Поэтому использовать таким образом организованные распределенные кластеры пока не получится.

В общем, мораль здесь в том, что перед обсуждением решения об имплементации той или иной архитектуры нужно почитать о ее ограничениях.

Мы много писали о новой версии решения для организации кластеров отказоустойчивых хранилищ VMware vSAN 8.0, в последней версии которого появилось много всего нового, в частности архитектура ESA (Express Storage Architecture). Это новая архитектура гиперконвергентной инфраструктуры, позволяющая достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Дункан Эппинг недавно рассказал о том, как в архитектуре ESA работает механизм адаптивного RAID-5. Он позволяет развернуть определенную конфигурацию RAID-5, в зависимости от того, сколько хостов ESXi находится в кластере vSAN. Базовое правило тут такое:

• RAID-5, конфигурация 2+1 - выставляется при 3-5 хостах в кластере
• RAID-5, конфигурация 4+1, выставляется при 6 и более хостах

При схеме 2+1 вы получите 50% надбавку к сырой емкости, то есть чтобы хранить 100 ГБ данных вам потребуется 150 ГБ хранилища.

Для конфигурации 4+1 (при 6 хостах и более) вы получаете меньшую потерю емкости - всего 25%, то есть для хранения данных в объеме 100 ГБ на Capacity leg вам потребуется всего 125 ГБ емкости.

Интересная особенность Adaptive RAID-5 в том, что он постоянно следит за размером кластера в реальном времени. То есть, если у вас есть 6 хостов, а один из них падает или переходит в режим обслуживания, то vSAN автоматически переключает конфигурацию с 4+1 на 2+1 по истечении 24 часов (а потом и обратно при восстановлении исходной конфигурации).

Функциональность адаптивного RAID-5 работает и в растянутом (stretched) кластере. То есть, если у вас растянутый кластер в схеме 3+3+1, то вы увидите в нем конфигурацию RAID-5 в схеме 2+1, а если у вас кластер 6+6+1 (или более), то конфигурация будет 4+1. Если вы поместите несколько хостов в режим обслуживания, то конфигурация также изменится с 4+1 на 2+1, а потом изменится обратно на 4+1, когда хосты ESXi снова будут введены в строй.

Ну и видео о том, как это работает на практике:

В этом году компания VMware в рамках анонсов конференции Explore 2022 выпустила новые версии платформ vSphere 8 и vSAN 8. Главным нововведением новой версии vSAN стало решение Express Storage Architecture. Это новая архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Традиционно, в vSAN одним из фундаментальных понятий были дисковые группы. Это объединения дисков на хостах ESXi, которые используются для функций хранения (Capacity tier) и кэширования (Caching tier). Необходимо было это для того, чтобы пользователи могли гибко управлять ресурсами HDD и SSD дисков с точки зрения емкостей (дешевле использовать HDD) и производительности кэша (лучше использовать SSD).

Так как архитектура ESA предназначена для высокопроизводительных хранилищ на SSD/NVMe носителях, то необходимость использования дисковых групп отпала - вместо них появился объект Storage Pool. Теперь пользователю не нужно указывать, какие диски будут использоваться для кэширования, а какие для хранения - все они вносят вклад, как в подсистему хранения, так и в подсистему кэширования на паритетной основе (операции ввода-вывода распределяются между устройствами равномерно, не создавая бутылочного горла).

Идея vSAN в том, чтобы обеспечивать скорость чтения на уровне RAID-1, а эффективность использования дискового пространства на уровне RAID-5 / RAID-6. Подсистема работы с хранилищами оптимизирована таким образом, что сейчас поддерживается память TLC, но и сделаны оптимизации для будущих устройств QLC. Об этом рассказал Дункан Эппинг.

Ключевые элементы новой архитектуры - это файловая система log-structured filesystem и специальный durable log. Давайте посмотрим на картинку:

Все данные, которые отправляются на запись в log-structured file system, сначала попадают в durable log. Это позволяет убедиться в том, что данные сохранятся персистентно. Этот durable log является частью блока Performance Leg, который спроектирован для того, чтобы операции записи сохранялись быстро и в первую очередь.

Performance Leg представляет собой конфигурацию уровня RAID-1, принимающую операции записи, которые мгновенно подтверждаются со стороны хранилища, а потом на нижнем уровне данные распределяются уже как избыточный страйп (RAID 5/6) на Capacity Leg. Для этого Performance Leg собирает stripe write размером 512 КБ и отсылает эти блоки на Capacity Leg, ну а для подстраховки этих процессов на случай сбоев у нас всегда есть durable log. Такая схема позволяет достичь наилучшего баланса с точки зрения производительность/доступная емкость в VMware vSAN 8.

Ну и посмотрите интересное видео от Дункана на эту тему:

Недавно мы писали о новой версии платформы VMware vSAN 8 и архитектуре ESA (Express Storage Architecture). На прошлой неделе состоялся релиз этого продукта в рамках доступности vSphere 8 Initial Availability.

Дункан Эппинг недавно рассказал о том, как работает сжатие и дедупликация в рамках этой архитектуры. Напомним, что главное отличие ESA от OSA (Original Storage Architecture) заключается в том, что она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения, таких как флэш-память TLC на основе технологии NVMe.

Ключевыми структурными особенностями vSAN 8 ESA является переработанная и запатентованная файловая система (log-structured file system, LFS), новый оптимизированный для записи менеджер объектов (log-structured object manager), а также новый формат дисковых объектов.

Итак, в архитектуре OSA сжатие и дедупликация срабатывают непосредственно до того, как данные сохраняются на диск на каждом из хостов, где они в итоге оказываются. В vSAN ESA сжатие данных (compression) включено по умолчанию и работает все время на самом верхнем уровне архитектуры (до низких уровней слоев vSAN), как показано на диаграмме ниже:

Суть изменения заключается в том, что данные сначала сжимаются, а только потом передаются по сети. Например, вы сжимаете блок 4К до 2К, и далее он отправляется в сеть. Это требует меньше канала, а также меньше ресурсов на шифрование - вам нужно посчитать контрольную сумму для 2К блока вместо 4К.

Сжатие данных происходит только на исходном хосте, а целевой хост отвечает только за их помещение на диски. Это уменьшает совокупное потребление ресурсов и более эффективно расходует пропускную способность сети.

При создании политики хранения на вкладке Storage rules вы можете выбрать один из четырех вариантов сжатия:

• No Preference (по умолчанию)
• No space efficiency
• Compression only
• Deduplication and compression

Надо отметить, что дедупликация данных еще не реализована для архитектуры ESA, поэтому вариант Deduplication and compression не актуален на данный момент.

Итак, как мы уже сказали компрессия включена по умолчанию, поэтому она будет работать при выбранных вариантах No Preference и Compression only. Если вы выберете No space efficiency, то сжатие данных будет отключено.

Дункан создал 3 виртуальных машины и три политики хранения. Машина VM_CompDisabled получила политику "Comp_Disabled", где выбран вариант "No space efficiency".

Пока нет способа в интерфейсе увидеть, включено реально ли сжатие в рамках политики или нет, но вы можете воспользоваться следующей командой, указал UUID объекта из скриншота выше:

cmmds-tool find -t DOM_OBJECT -u <UUID>

Если в выводе команды вы найдете строку ("compressionState" i1), то это значит, что компрессия данных отключена:

Еще один момент - так как компрессия работает на верхнем уровне и не имеет связи с оборудованием и компонентами хостов ESXi, то при изменении политики хранения не происходит переработки уже записанных данных. Просто все новые данные, приходящие на источник, начинают (или прекращают) сжиматься и в этом виде попадают на хранилища.

На сайте проекта VMware Labs обновилось средство HCIBench до версии 2.8.0. Напомним, что оно предназначено для проведения комплексных тестов производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.6 мы писали вот тут.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Давайте посмотрим, что нового в HCIBench 2.8.0:

• Компонент fio обновлен до версии 3.30
• Добавлен целевой параметр latency для fio
• Исправлена уязвимость CVE-2021-40438
• Добавлен vSAN support bundle graph для режима vSAN Debug mode
• Улучшен отчет об использовании ресурсов
• Добавлена поддержка возможности тестирования vSAN 8 ESA
• Исправлена ошибка при тестировании на архитектуре VMware Cloud

Скачать HCIBench 2.8.0 можно по этой ссылке.

Недавно мы писали о новой схеме релизов платформы VMware vSphere. Согласно ей, вводится два типа выпусков - IA (Initial Availability) и GA (General Availability), которые позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.

Вчера VMware объявила о доступности vSphere 8 Initial Availability - продукт можно скачать по этой ссылке. О возможностях новой версии платформы мы писали вот тут.

Вместе с vSphere 8 стала доступна для загрузки и платформа для организации отказоустойчивых хранилищ VMware vSAN 8:

Документация к релизу:

• VMware vSphere 8.0 Release Notes
• VMware vSAN 8.0 Release Notes

IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы.

Ставить этот релиз в производственной среде вы можете, но это не рекомендуется. Пока его лучше обкатывать на тестовых серверах и смотреть, как все работает (особенно новый функционал платформы). После выхода vSphere 8 General Availability можно смело устанавливать продукт на свои производственные серверы, так как все критичные проблемы первоначального релиза будут уже решены.

На сайте проекта VMware Labs обновилась полезная утилита vSAN Hardware Compatibility List Checker 3.0, предназначенная для проверки соответствия хостов ESXi требованиям списка совместимости для узлов кластера vSAN. О прошлой версии этой утилиты мы писали вот тут.

Что нового в vSAN HCL Checker 3.0:

• Новая таблица Summary, где можно увидеть, какие устройства совместимы с vSAN и vSAN ESA в рамках общего отчета
• Проверка совместимости оборудования для режима vSAN ESA (Express Storage Architecture), начиная с версии ESXi 8.0
• Поправлен формат отчета
• Исправления ошибок, в том числе с обнаружением контроллеров

Для vSAN проверяются Storage adapters на хранилищах, а для режима vSAN ESA проверяются также скорость физических сетевых соединений (суммарно 25 Gbps и более) и размер памяти хостов (32 ГБ и более).

vSAN ESA (Express Storage Architecture)

• Storage adapters
• Physical NIC link speed
• Host memory size

Также отметим, что в версии 2.2 появилась поддержка Windows, Linux и MacOS для запуска утилиты.

Для начала работы нужно просто запустить утилиту и в интерактивном режиме ввести имя хоста ESXi и пароль пользователя root:

В качестве результата в папке с утилитой будет сформирован html-файл (этот шаблон можно редактировать в файле reportTemplate.html), в котором будет информация о совместимости контроллеров хранилищ со списком vSAN HCL (шильдики yes и N/A).

Скачать VMware vSAN Hardware Compatibility List Checker 3.0 можно по этой ссылке.